Bounded Contexts Are Org Charts in Disguise
Conway's Law says systems mirror the communication structure of the organizations that build them. Domain-Driven Design says a bounded context should mirror the domain. Most of the time, the domain loses that argument.
The Textbook Definition vs. the Whiteboard Reality
On paper, a bounded context is a boundary around a specific domain model, drawn where the meaning of a term genuinely changes. "Customer" in Billing means something different from "Customer" in Support — different attributes, different lifecycle, different invariants — so they get separate models, separate contexts, separate services if you go that far.
In practice, walk into most architecture reviews and you'll find the bounded context diagram was drawn after the org chart, not before it. The Payments team owns the Payments context. The Fulfillment team owns the Fulfillment context. Nobody sat down and asked whether "Order" means something different in each — they drew a box around what the team already owned and called it a bounded context because that's the word for the box shape everyone recognizes.
This Isn't Necessarily Wrong
Eric Evans' own writing on bounded contexts leans on team ownership as a real, load-bearing signal — a model maintained by one team, speaking one ubiquitous language, is far more likely to stay coherent than a model edited by five teams with five different incentives. Conway's Law isn't a bug you're supposed to design around; in this specific case, it's often pointing at the right answer for the wrong reason.
The failure mode isn't "the org chart influenced the boundaries." It's when the org chart is the only input, and nobody goes back to check whether the resulting boundary actually isolates a coherent model — or whether it just isolates a coherent team, with a model that's incoherent underneath and papered over by whoever's on call that week.
The Tell: Boundaries That Move When the Team Doesn't
Here's a diagnostic that costs nothing: watch what happens when a reorg splits a team in two, or merges two teams into one, without any change to the underlying business. If your bounded contexts redraw themselves along with the new team boundaries — the same domain concepts, the same invariants, just re-partitioned to match new reporting lines — that's a strong signal your "domain model" was a team-ownership map wearing a domain-modeling hat.
A context boundary anchored in the actual domain shouldn't care who's on call. Marketing and Sales can merge into one org and split back apart next quarter; the fact that "Lead" and "Opportunity" are distinct concepts with distinct lifecycles doesn't change because a VP redrew some boxes in a slide deck.
Where This Actually Bites
The expensive version of this mistake shows up at integration points. Two teams each own a context, each context has a model of "Order," and because the boundary was drawn by team rather than by meaning, both models are trying to represent the same concept instead of two genuinely different ones. Now every change to "Order" needs a cross-team negotiation, translation layers appear at every integration point, and someone eventually asks "why do we have three services that all basically know what an order is?" The answer is: because three teams needed to own something, and "Order" was the noun everyone could agree existed.
Contrast that with a boundary drawn around actual semantic divergence — Billing's "Order" really is a different object from Fulfillment's "Order," with different fields, different state transitions, different failure modes. There, the translation layer at the boundary isn't overhead, it's the point: it's doing real work reconciling two models that are legitimately different, not two copies of the same model that drifted apart because nobody was allowed to look across the org chart.
What to Do About It
Before finalizing a bounded context boundary, ask the question in the other direction: if a single team owned both halves, would you still draw a line here? If the honest answer is "no, we'd model this as one thing," you don't have a bounded context — you have two teams sharing custody of one concept, and the boundary is going to cost you in translation and drift for as long as it exists.
If the answer is "yes, even one team would keep these separate because the concepts genuinely diverge," then you've found a real boundary, and it's fine — good, even — that it also happens to line up with who's on call. Team ownership and domain boundaries agreeing with each other isn't a coincidence to be suspicious of. It's what Conway's Law predicts when the org chart and the domain model were both drawn by people paying attention.
FAQ
Is Conway's Law itself a good thing or a bad thing for architecture?
Neither — it's a description of what happens, not a prescription. It becomes a problem only when the team structure is treated as the sole input into architectural boundaries, with no check on whether those boundaries also make sense from the domain's perspective.
Should we redesign our bounded contexts every time we reorg?
No. If your contexts are correctly anchored in real domain divergence, a reorg shouldn't force a redesign at all — the same teams-to-context mapping might change, but the contexts themselves stay put. Needing to redraw contexts after every reorg is itself a signal they were team-shaped, not domain-shaped.
What's the "reverse Conway maneuver"?
It's the practice of deliberately restructuring teams to match the bounded contexts you actually want, rather than letting an existing org chart dictate the architecture. It's a useful tool once you've done the harder work of figuring out where the real domain boundaries are.
How many bounded contexts should a small team own?
There's no fixed number — it depends on how many genuinely distinct models the domain requires. A single small team can legitimately own several bounded contexts, especially early on, as long as the team keeps the models conceptually separate rather than letting them bleed into one shared, muddled model for convenience.
